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(57) Abstract 
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The invention relates to a program flow 
method in a program component system which has 
a running lime system (14) and a number of com- 
ponents (20, 20*, ...). The inventive method com- 
prises a data acquisition of data pertaining to a sec- 
ond component (20') in the first component (20) 
independent of programming-defined interfaces in 
the second component (20'), said data acquisition 
being conveyed by the running time system (14). 
The inventive method also comprises a data ac- 
quisition of data pertaining to the first component 
(20) in the second component (20*) independent 
of programming-defined interfaces in the second 
component (20*). In a method for expanding a pro- 
gram component system around an additional com- 
ponent, the invention provides that docking points 
are to be searched for the additional component, 

and the respective components (20, 20',.,.) of the program component system in which at least one docking point has been found are to 
be changed by registering call information on each docking point which has been found. The invention permits an especially flexible and 
extensive expansion of a program component system. 
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(57) Zusammenfassung 

Ein Programmablaufverfaren bei einem Programmkomponentensystem, das ein Laufzeitsystem (14) und mehrere Komponentcn 
(20, 20\ ...) aufweist, enthalt eine durch das Laufzeitsystem (14) vermittelte Datenbesorgung von Daten einer zweiten Komponente 
(20*) in die erste Komponente (20) unabhangig von programmiererdefinierten Schnittstellen in der zweiten Komponente (20*) und eine 
durch das Laufzeitsystem (14) vemiittelte Datenentsorgung von Daten der ersten Komponente (20) in die zweite Komponente (20*) • 
unabhangig von programmiererdefinierten Schnittstellen in der zweiten Komponente (20'). Bei einem Verfahren zur Erweiterung eines 
Programmkomponentensy stems um eine weitere Komponente ist vorgesehen, Andockpunkte fiir die weitere Komponente zu suchen und 
diejenigen Komponenten (20, 20*, ...) des Programmkomponentensystems, in denen mindestens ein Andockpunkt gefunden wurde, 
zu andem» indem an jedem gefixndenen Andockpunkt eine Aufrufinfomiation eingetragen wird. Die Erfindung ermftglicht es, ein * 
Programmkomponentensystem besonders flexibel und weitgehend zu erweitem. 
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Programmablaufverf ahren und Verfahren zur Erweiterxing eines 
Programiakomponent ensys terns 

Die Erfindiing betriff t den Prograininablauf sowie die Erstel- 
lung eines Programmkomponentensys terns , das auch als "Compo- 
nentware" bezeichnet wird. Insbesondere betrifft die Erfin- 
d\ing ein Programmablaufverf ahren bei einem Programmkompo- 
nentensystem sowie ein Verfahren zur Erweiterting eines sol- 
chen Systems. 

In dem Artikel "Componentenware - von der Komponente zur 
Applikation" von Michael Stal, erschienen in der Zeitschrift 
OBJEKTspektrum, Heft 3, 1997, Seiten 86 bis 89, sind Grund- 
lagen von Programmkomponentensystemen beschrieben. Die Ziel- 
setzung ist es, die bisher erf orderliche, sehr zeitaufwendi- 
ge Sof twareerstellung durch ein bloSes "Verdrahten" vorgege- 
bener Koit5)onenten zu ersetzen. Diese Komponenten sollen in 
iinterschiedlichen Kontexten eingesetzt werden konnen, ohne 
dafi der Koit^onentenproduzent Details des einer Komponente 
zugrundeliegenden Source-Codes bekanntgeben miifite, 

Zur Produktion von Componentware sind mehrere sich erganzen- 
de Technologien bekannt, darunter Verteilungsplattf ormen, 
Containerplattf ormen und die Verbunddokumenten-Technologie, 

Bei Verteilungsplattf ormen werden Konventionen und Werkzeuge 
fiir die Verteilung von Komponenten tiber Rechnergrenzen hin- 
weg sowie zur Kommunikation zwischen den Komponenten bereit- 
gestellt- Als Quasi-Industriestandards haben sich folgende 
Verteilungsplattf ormen durchgesetzt : DCOM {Distributed Com- 
ponent Object Model) von Microsoft, CORBA (Common Object 
Request Broker Architecture) von der OMG (Object Management 
Group) , JAVA-RMI (Remote Method Invocation) von JavaSoft. 

Containerplattf ormen beinhalten eine losungsorientierte 
Menge von Sof twarekomponenten zur zumindest teilweisen 
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Abdeckung eines bestimmten Auf gabenbereichs (zum Beispiel 
Lagerwesen, Finanzbuchhaltung, ...) und eine losungsneutrale 
Middleware (wie zum Beispiel eine graphische Benutzer- 
schnitts telle) , um eine Interaktion zwischen den Komponenten 
und dem Benutzer zu ermoglichen . 

Die Verbunddokumenten-Technologie ermoglicht eine Integra- 
tion unterschiedlicher Applikationen . Ein Verbunddokument 
umfaSt mebrere Bestandteile (zum Beispiel Tabellen, Grafi- 
ken, Texte, . . . ) , fur die je eine Applikation verantwortlich 
ist. Bekannte Architekturen fiir Verbunddokumente sind bei- 
spielsweise ActiveX von Microsoft, OpenDoc von CILab und 
Java Beans von JavaSoft. 

Bei den verfugbaren Verfahren besteht jedoch das Problem, 
dafi die Funktionalitat einer Komponente ausschlieSlich viber 
Schnittstellen genutzt werden kann, die von dem Komponenten- 
produzenten vordefiniert worden sind. Diese Schnittstellen 
sind insbesondere die vom Komponentenproduzenten vordefi- 
nierten Methoden oder Parameter. Es besteht keine Moglich- 
keit, die Funktionalitat einer Komponente unabhangig vom 
Komponentenproduzenten zu erweitern, da der Source-Code der 
Komponente im allgemeinen nicht verfugbar ist. Eine bloSe 
Parametrisierungsmoglichkeit , wie sie gegebenenf alls vorge- 
sehen sein kann, stellt keine Erweiterung der Funktionalitat 
einer Komponente dar, da alle moglichen Funktionen bereits 
ursprunglich vom Komponentenproduzenten vorgesehen sein miis- 
sen. 

Die Erfindung hat demgemafi die Aufgabe, bei einem Programm- 
komponentensystem eine besonders flexible und weitgehende 
Erweiterbarkeit zu ermoglichen. Insbesondere soil die Funk- 
tionalitat einer Komponente verandert und/oder erweitert 
werden konnen, ohne dafi dazu Kenntnisse des Source-Codes der 
zu erweiternden Komponente erforderlich sind. 
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Erf indungsgemaB wird diese Aufgabe durch ein Programmablauf - 
verfahren bei einem Programmkomponentensystem mit den Merk- 
malen des Anspruchs 1 sowie durch ein Verfahren zur Erweite- 
rung des Programmkomponentensys terns xnit den Merkmalen des 
Anspruchs 10 gelost. 

Im folgenden wird die zu erweiternde Komponente als "Grund- 
komponente" und die neu hinzuzuf ligende Komponente als "Er- 
weiterungskomponente" bezeichnet . 



Die Erfindung geht von der Grundiiberlegung aus, eine nahezu 
beliebige Erweiterbarkeit der Grundkomponente dadurch zu 
erzielen, da£ auf das Erfordernis einer vom Programmierer 
definierten Erweiterungsschnittstelle in der Grundkomponente 

15 verzichtet wird. Vielmehr legt der Produzent der Erweite- 

rungskomponente fest, wie die Erweiterungskomponente mit der 
Grundkomponente zusammenwirken soli. Diese Grundidee stellt 
eine Umkehrung der bisher in der Informatik iiblichen Prinzi- 
pien (encapsulation, information hiding, dar. Uberra- 

20 schenderweise lassen sich jedoch gerade durch diese Abkehr 

von etablierten Grundsatzen relativ grofie Sof twaresysteme in 
erstaunlich kurzer Zeit auch durch Nicht-Programmierer 
realisieren . 

25 Die erf indungsgemafie Uberlegung, die Erweiterungsschnitt- 
stellen nicht durch den Programmierer der Grundkomponente, 
sondern durch den der Erweiterungskomponente festlegen zu 
lassen, bedingt eine Umkehr von gewohnten Denkweisen wahrend 
des Programmablauf s sowie wahrend des Einbindens einer Er- 

3 0 weiterungskomponente in ein bestehendes Programmkomponenten- 
system. Diese beiden Falle sind Gegenstand der nebengeordne- 
ten Ansprliche 1 und 10. 

Wahrend des Programmablauf s benotigen Komponenten iiblicher- 
3 5 weise Daten voneinander, um sie zu verarbeiten und Ergeb- 

nisse zu erzeugen. Es ist bekannt, eine aufgerufene Prozedur 
von der aufrufenden Stelle mit Daten zu versorgen und die 
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Ergebnisse beim Riicksprung zuriickzugeben . Dieses Verfahren 
setzt jedoch voraus, dafi die Auf ruf schni ttstelle vom Pro- 
grammierer der aufrufenden Prozedur vordefiniert ist. 

Erf indungsgemaS ist dagegen vorgesehen; da£ sich die aufge- 
rufene Komponente - uber ein geeignetes Lauf zeitsystem - die 
benotigten Daten selbst beschafft. Dieser Vorgang wird im 
folgenden als "Datenbesorgung" bezeichnet. In der Komponen- 
te, von der Daten besorgt werden, mussen keine besonderen 
Schnittstellen vom Programmierer festgelegt worden sein. 
Entsprechend ist es eine Aufgabe der aufgerufenen Komponen- 
te, die Ergebnisse an geeignete Stellen anderer Komponenten 
einzuspeictiern. Dieser Vorgang wird als "Datenentsorgung" 
bezeichnet. Auch hier ist es nicht erf orderlich, dafi der 
Programmierer besondere Schnittstellen fiir die Datenentsor- 
gung vorgesehen hat. In diesem Zusammenhang soil die bloSe 
Definition oder Deklaration eines Datenfeldes oder einer 
Variablen (gegebenenf alls einschlieSlich einer Typangabe und 
weiterer Parameter) nicht als eine " Schni ttstelle " angesehen 
werden. Eine Schnitts telle waren dagegen zum Beispiel proze- 
durale Anweisungen, die vom Programmierer explizit in ein 
Komponentenskript eingefiigt werden mussen, um zur Laufzeit 
einen Datentransf er zu veranlassen oder zu ermoglichen. 

Beim Anbinden einer Erweiterungskomponente an ein bestehen- 
des Programmkomponentensystem werden die bekannten Prinzi- 
pien in entsprechender Weise umgekehrt . Normalerweise wiirde 
man erwarten, daS die bisherigen Komponenten des Programm- 
komponentensystems durch die Erweiterung unverandert blei- 
ben. Erf indungsgemafi ist dagegen vorgesehen, im Programm- 
komponentensystem nach Andockpunkten fiir die Erweiterungs- 
komponente zu suchen, und diejenigen Komponenten des Pro- 
grammkomponentensystems , in denen mindestens ein Andockpunkt 
gefunden wurde, zu andern, indem an jedem gefundenen Andock- 
punkt eine Auf ruf information auf die neue Komponente einge- 
tragen wird. Es wird also potentiell jede Komponente des 
gesamten Programmkomponentensys terns verandert . 
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Durch die erf indungsgemaSe Losung wird es moglich, weitge- 
hende Erweiterungen der Funktionalitat eines Programmkompo- 
nentensystems durchzuf uhren, ohne daS solche Moglichkeiten 
5 vom Programmierer der bisherigen Komponenten bereits ge- 
plant, vorgesehen oder vorgedacht sein mu£ten. Dies stellt 
einen wesentlichen Fortschritt gegenuber den bisher bekann- 
ten Programmkomponentensystemen dar. 

10 Unter dem Begriff "Lauf zeitsystem" werden in der Wortwahl 
dieser Anmeldung insbesondere alle generischen Routinen 
verstanden; also solche Routinen, die nicht vom Programmie- 
rer einer Komponente explizit vorgegeben werden. Hierbei 
kann das Lauf zeitsystem auch Anteile aufweisen, die in den 

15 Komponenten enthalten sind. Beispielsweise kann derjenige 

Teil des Lauf zeitsys terns , der den Datentransf er vornimmt, in 
die einzelnen Komponenten ver lager t sein. 

Die bei der Datenbe- und -entsorgung ubermittelten Daten 
2 0 sind bevorzugt nicht allgemein zuganglich, sondern derjeni- 
gen Komponente zugeordnet, von der die Daten besorgt bezie- 
hungsweise in die sie entsorgt werden, Diese Daten werden in 
bevorzugten Ausf uhrungsf ormen iibertragen, wahrend die ge- 
nannte Komponente inaktiv ist. Insbesondere kann diese Kom- 
25 ponente zum Zeitpunkt der Datenbe- und -entsorgung aus dem 

regularen Arbeitsspeicher ausgelagert sein, Bevorzugt werden 
bei der Datenbe- und/oder -entsorgung lokale und/oder nicht- 
persistente Daten ubermittelt, also insbesondere keine 
global verfugbaren Daten. 

30 

Bevorzugt erfolgt die Datenbe- und/oder -entsorgung ohne 
Mitwirkung der Komponente, von der die Daten besorgt bezie- 
hungsweise in die sie entsorgt werden. Beispielsweise kann 
vorgesehen sein, bei einer Datenentsorgung lediglich die 
35 entsorgende Komponente sowie das Lauf zeitsystem zu beteili- 
gen. Diejenigen Komponente, in die die Daten abgelegt wer- 
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den, hat in bevorzugten Ausf uhrungsf ormen keine Einflufimog- 
lichkeit . 

Vorzugsweise werden beim Ausfiihren einer Komponente diejeni- 
gen Datenf elder vorgemerkt, fur die eine Datenentsorgung 
erforderlich ist. Dies konnen insbesondere Datenf elder sein, 
deren Inhalte durch eine Datenbesorgung erraittelt wurden und 
auf die ein Schreibzugrif f erfolgt ist. 



Bevorzugt ist ferner vorgesehen, daS eine aufgerufene Kompo- 
nente unmittelbar auf in der aufrufenden Komponente defi- 
nierte und/oder verfiigbare Datenfelder lesend und schreibend 
zuzugreifen verraag . Dies ermoglicht einen quasi schnittstel- 
lenfreien Datenaustausch zwischen den beiden genannten Kom- 
15 ponenten. Der Aufruf einer Komponente wird vorzugsweise 

durch eine in einem Andockpunkt der aufrufenden Komponente 
enthaltene Auf ruf information oder -nachricht ausgelost. Die 
Verwendung von Andockpunkt en, die Auf ruf inf ormationen auf- 
nehmen konnen, ermoglicht eine besonders flexible Funktio- 
20 nalitatserweiterung . 

Als potentielle Andockpunkte sind bevorzugt alle Interak- 
tionsschnittstellen einer Komponente vordef iniert . Solche 
Interaktionsschnittstellen konnen Interaktions-Bildschirm- 

25 f elder sein, zum Beispiel Eingabef elder oder Schaltf lachen . 
Ferner konnen alle Ausgabef elder einer Druckmaske und/oder 
alle Zugrif f soperationen auf persistente Daten (zxim Beispiel 
Offnen, Lesen und Schreiben einer Datei oder einer Daten- 
bank) als Interaktionsschnittstellen vorgesehen sein. Inter- 

3 0 aktionsschnittstellen konnen in bevorzugten Ausf uhrungsf or- 
men auch vom Programmierer einer Komponente vorgegeben sein. 

Vorzugsweise werden bei dem Einbinden einer weiteren Kompo- 
nente in das Programmkomponentensystem alle moglichen An- 
35 dockpunkte automatisch (und ohne Kenntnis des Source-Codes 
der bereits vorhandenen Komponenten) identif iziert . Damit 
ist eine Erweiterung mit geringem Programmieraufwand mog- 
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lich. Ferner warden bevorzugt geeignete Auf ruf inf ormationen 
in mindestens einen Andockpunkt eingetragen. 

In bevorzugten Ausges taltungen enthalt das Verfahren zur 
5 Komponentenerweiterung den weiteren Schritt, mindestens eine 
Komponente als Binarobjekt zu erzeugen. Insbesondere kann 
fur jeden gefundenen Andockpunkt genau oder hochstens ein 
Binarobjekt generiert werden . In diesem Binarobjekt kann die 
Speicherzuteilung des Programmkomponentensys terns zur spate- 
10 ren Laufzeit berucksichtigt werden. 

Weitere bevorzugte Ausf uhrungsf ormen sind Gegenstand der 
Unteransprliche . 

15 Ein Ausfiihrungsbei spiel der Erfindung und mehrere Ausfuh- 

rungsvarianten werden im folgenden anhand der schematischen 
Zeichnungen genauer erlautert . 

Fig. 1 zeigt eine Prinzipdarstellung des Prograimtikomponen- 
2 0 tensys terns wahrend der Liaufzeit, 

Fig. 2 zeigt eine Prinzipdarstellung eines Binarobj ekts , 

Fig. 3 zeigt ein FluBdiagramm der Instantiierung von Kompo- 
25 nenten, 

Fig. 4a bis Fig. 4c zeigen ein FluSdiagramm des Berechnungs- 
ablaufs zur Laufzeit einschlieSlich eines Komponentenwech- 
sels. 

30 

In Fig. 1 ist die Struktur des Programmkomponentensys terns 
wahrend der Laufzeit veranschaulicht . Ein Betriebssystem 10, 
beispielsweise ein ubliches Fensterbetriebssystem, ist xim 
eine Verteilerplattf ormschicht 12, zum Beispiel DCOM oder 
35 CORBA, erweitert, Auf die Verteilerplattf ormschicht 12 setzt 
ein Lauf zeitsystem 14 auf, das auch als "Middleware" be- 
zeichnet wird. Das Betriebssystem 10 stellt einen Arbeits- 
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speicherbereich 16 bereit, der von dem Lauf zeitsystem 14 
verwaltet und genutzt wird. In einer Ausf iihrungsvariante ist 
die Verteilerplattf ormschicht 12 weggelassen, und das Lauf- 
zeitsystem 14 setzt unmittelbar auf das Betriebssys tern 10 
auf . Das Programmkomponentensystem wird von einem handels- 
iiblichen Computer, beispielsweise von einem PC-kompatiblen 
Rechner , ausgef tihrt . 

Neben dem Lauf zeitsystem 14 weist das Programmkomponenten- 
system eine Containerumgebung 18 auf, die mehrere Komponen- 
ten 20, 20', 20*', 20''' in Form von Binarobjekten enthalt. 
Die Komponenten 20, 20' , 20* ' , 20* ' ' bestimmen das Verhalten 
des Programmkomponentensys terns . Sie werden - beispielsweise 
in Abhangigkeit von Ereignissen, die der Benutzer auslost - 
von dem Lauf zeitsystem 14 aufgerufen. 

Eine Komponente 2 0 im Binarobj ektf ormat weist, wie in Fig. 2 
dargestellt, mehrere Abscimitte auf, und zwar einen Pro- 
grammabschnitt 22, einen Tabellenabschnitt 24, einen Ver- 
zeichnisabschnitt 26 und einen Speicherbildabschnitt 28. 

Der Programmabschnitt 22 enthalt interpretierbaren Code, der 
zur Laufzeit von dem Lauf zeitsystem 14 interpretiert wird 
und das Verhalten der Komponente 2 0 bestimmt. Der im Pro- 
grammabschnitt 22 enthaltene Code ist in einem Zwischenfor- 
mat, das eine effiziente Ausfiihrung zur Programmlauf zeit er- 
laubt. In Ausf lihrungs alt ernativen ist eine geeignete Kompi- 
lierung des Codes zur unmittelbaren Ausfiihrung unter Kon- 
trolle des Betriebs systems 10 vorgesehen. 

Im Tabellenabschnitt 24 sind Lauf zeittabellen fur konfigu- 
rierbare Eigenschaf ten und Parameter des Codes gespeichert. 
Dies sind beispielsweise Inf ormationen liber FenstergroSen 
und Farben fiir die Bildschirmdarstellung oder Inf ormationen 
fiir die Druckdarstellung . Au£erdem enthalten die Lauf zeit- 
tabellen Verwaltungsinf ormationen fiir die Speicherzuteilung . 
Der Verzeichnisabschnitt 26 beinhaltet ein Verzeichnis der 
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Andockref erenzen, ein Speicherverzeichnis , ein Datentrans- 
f erverzeichnis und ein Methodenverzeichnis . 

Das Speicherverzeichnis enthalt die in der Koinponente ver- 
5 fiigbaren Bezeichnungen fur Speicherf elder , Inf ormationen zu 
den Speicherf eldern sowie Verweise (genauer gesagt, Offset- 
oder Displacementwerte) darauf . Das Methodenverzeichnis 
enthalt eine Liste der von der Koinponente bereitgestellten 
Methoden. Diese beiden Verzeichnisse sind im Binarobjekt 

10 enthalten, damit auch ohne Kenntnis des Source-Codes einer 

Koinponente (Komponentenskript ) eine Erweiterung der Funktio- 
nalitat einer Komponente moglich ist. Alle im Speicherver- 
zeichnis enthaltenen Speicherf elder sind durch die Operatio- 
nen der Datenbe- und -entsorgung von beliebigen anderen Kom- 

15 ponenten aus zuganglich und konnen gelesen, verandert und 

beschrieben werden. Der Programmierer hat im hier beschrie- 
benen Aus fiihrungsbei spiel keine Moglichkeit, einzelne Spei- 
cherf elder vor fremdem Zugriff zu schiitzen. Inf ormationen, 
die bei der Laufzeit zur Datenbe- und -entsorgung benotigt 

2 0 werden, sind im Datentransf erverzeichnis en thai ten. 

Im Speicherbildabschnitt 2 8 sind drei zusammenhangende Da- 
tenbereiche 30, 32, 34 vorgesehen, deren Grenzen durch die 
Verwaltungsinf ormationen in den Lauf zeittabellen angegeben 
25 werden. Der erste Datenbereich wird im folgenden als Zu- 
griff sdatenbereich 3 0 bezeichnet. Er ist fur diejenigen Da- 
ten reserviert, die von einer innerhalb der Auf rufhierarchie 
ubergeordneten Komponente stammen. Diese Daten kann die auf- 
gerufene Komponente unmittelbar lesen, verarbeiten und 

3 0 schreiben, ohne dafi ein programmierter Datentransf er notwen- 

dig ware. Ubertragen auf eine prozedurale Programmiersprache 
entspricht dies ungefahr der Moglichkeit, unmittelbar auf 
Variablen zuzugreifen, die in einer statisch ubergeordneten 
Prozedur definiert sind. Die Grofie des Zugriff sdatenbereichs 
3 5 3 0 wird bei der Instantiierung einer Komponente 2 0 festge- 
legt. Dies ist moglich, weil jede Komponente 2 0 im Binarob- 
jektformat nur genau einer moglichen Auf rufs telle (einem An- 
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dockpunkt) zugeordnet ist. Die Groge des Zugrif f sdatenbe- 
reichs 3 0 einer Komponente 2 0 ist die Summe der GroSen des 
Zugrif fsdatenbereichs und des (noch zu beschreibenden) Lo- 
kaldatenbereichs der aufrufenden Komponente. 

Als zweiter Datenbereich im Speicherbildabschnitt 2 8 einer 
Komponente 2 0 ist der Lokaldatenbereich 3 2 vorgesehen. Die- 
ser Datenbereich schlieiSt unmittelbar an den Zugrif fsdaten- 
bereicb 3 0 an. Er enthalt diejenigen Daten, die in der 
Komponente 2 0 neu definiert werden. Eine solche Definition 
kann unmittelbar in der Komponente oder indirekt - zum Bei- 
spiel durch eine Referenz auf eine Bildschirmmaske oder ein 
Druckformat - erfolgen. Ubertragen auf eine prozedurale Pro- 
grammiersprache enthalt der Lokaldatenbereich 32 ungefahr 
die lokalen Variablen einer Prozedur. 

SchlieSlich ist als dritter Datenbereich im Speicherbild- 
abschnitt 28 ein Trans ferdatenbereich 3 4 vorgesehen. Der 
Transferdatenbereich ist zur Zwischenspeicherung von Daten 
reserviert, die wahrend der Programmlauf zeit von einer an- 
deren Komponente nach dem Datenbesorgungsprinzip besorgt und 
nach dem Datenentsorgungsprinzip in diese entsorgt werden. 

Wenn eine Komponente 2 0 instantiiert , also aus einem Kompo- 
nentenskript in mindestens ein Binarobjekt ubersetzt wird, 
brauchen der Zugrif fsdatenbereich 3 0 und der Transferdaten- 
bereich 34 nicht mit definierten Werten belegt zu werden, 
weil diese Bereiche zur Laufzeit sowieso iiberschrieben wer- 
den. Der Lokaldatenbereich 32 wird mit vorgegebenen Stan- 
dardwerten fur die einzelnen Datentypen gefullt. Wahrend der 
Laufzeit eines Programmkomponentensys terns dienen die drei 
Datenbereiche 30, 32 und 34 einer Komponente 20 zur Zwi- 
schenspeicherung des jeweils aktuellen Systemzustandes bei 
jedem Aufruf einer weiteren Komponente und zum teilweisen 
Wiederherstellen dieses Zustandes (hinsichtlich des Lokal- 
datenbereichs 32 und des Trans ferdatenbereichs 34) bei einem 
Rucksprung . 
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Zur Erzeugung einer Komponente erstellt der Prograininierer 
ein Komponentenskript, das zur automatischen Ubersetzung 
itiittels eines Generatorsystems geeignet ist. Dieser auch als 
Instantiierung einer Komponente bezeichnete Ubersetzungsvor- 
gang wird unten genauer beschrieben. Das Komponentenskript 
stellt die Definition der zu generierenden Komponente dar. 
Es enthalt Anweisungszeilen, die als interpretierbarer Code 
der Komponente ubersetzt werden. Die verwendete Programmier- 
sprache ist an sich bekannt und beruht auf obj ektorientier- 
ten Prinzipien. Aufierdem kann das Komponentenskript Anwei- 
sungszeilen enthalten, die vom Programmierer vorgedachte An- 
dockpunkte fur Ei^A^eiterungen bestimmen. Optional konnen auch 
Daten und Parameter in einem Komponentenskript enthalten 
15 sein, zum Beispiel Parameter fur die visuelle Darstellung 
von Daten oder eine Aufzahlung zulassiger Eingabewerte . 
Weiter konnen im Komponentenskript Anweisungen zum Aufruf 
von " Fremdprogrammen " enthalten sein. Wahrend der Laufzeit 
wird dann das entsprechende Programm, beispielsweise ein 
20 COBOL- Programm, gestartet. Dieses Programm kann nun*sei- 

nerseits Schnittstellen des Programmkomponentensystems nut- 
zen und beispielsweise weitere Komponenten star ten. 

Ferner kann das Komponentenskript Referenzen auf zu verwen- 
25 dende Bildschirmmasken und -formate sowie auf Druckformate 
enthalten. Solche Bildschirmmasken oder Druckformate werden 
vorab mittels eines geeigneten graphischen Werkzeugs ent- 
wickelt. Das Werkzeug ("GUI-Builder") erzeugt mehrere globa- 
le Verzeichnisse, auf die wahrend jedes Instantiierungsvor- 
gangs einer Komponente zugegriffen wird. Dies sind erstens 
ein globales Verzeichnis der verfiigbaren Bildschirmmasken 
und Druckformate, zweitens ein Verzeichnis der durch diese 
Masken und Formate vorgegebenen Andockpunkte und dr it tens 
ein Verzeichnis der Bezeichner und Typen der in den defi- 
35 nierten Eingabef eldern beziehungsweise Druckfeldern erwar- 
teten Daten. 
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Falls es sich bei dem Komponentenskript urn die Definition 
einer Erweiterungskomponente handelt, also einer Komponente, 
die eine bereits bestehende Komponente (Grundkomponente) er- 
weitern soli, enthalt das Komponentenskript ferner einen 
Vererbungsparameter , der die gewunschten Andockpunkte fur 
die Komponentenerweiterung spezif iziert . Der Vererbungspara- 
meter kann, wie noch erlautert wird, mehr als eine Grundkom- 
ponente und mehr als einen Andockpunkt definieren. 



Als Andockpunkte dienen generische oder vom Programmierer 
angegebene Stellen der Grundkomponente, an denen eine Auf- 
ruf inf oormation fur eine Erweiterungskomponente eingefugt 
werden kann. Die Andockpunkte einer Komponente im Binar- 
objektformat konnen automatisch identif iziert werden, so dai^ 
15 eine Komponentenerweiterung ohne Kenntnis des Source-Codes 
der Grundkomponente moglich ist. 

Im hier beschriebenen Ausf lihrungsbeispiel sind vier Arten 
von Andockpunkten vorgesehen. Erstens sind als Andockpunkte 

2 0 arie Eingabef elder und sonstige Bedienelemente ( Knopf e, 

Schaltf lachen, ...) in den Bildschirmmasken vorgesehen, auf 
die die Grundkomponente zugreift. Damit ist es zum Beispiel 
moglich, Komponentenerweiterungen immer dann aufzurufen, 
wenn der Benutzer eine Interaktion mit einem Eingabefeld der 

25 Grundkomponente durchfuhrt, beispielsweise einen Wert ein- 
gibt Oder das Eingabefeld aktiviert oder mit dem Mauszeiger 
iiberfahrt. Der Programmierer der Grundkomponente braucht 
diese Moglichkeit nicht explizit vorzusehen. Ebenso dienen 
alle Druckmasken-Ausgabef elder als Andockpunkte, so daS bei- 

30 spielsweise durch eine Komponentenerweiterung die Ausgabe- 

werte einer auszudruckenden Tabelle verandert werden konnen. 

Als Andockpunkte sind ferner alle Operationen der Grundkom- 
ponente auf persistente Daten (beispielsweise Datei- oder 
35 Datenbankzugrif f e) vorgesehen. Auch hier konnen Earweite- 

rungskomponenten " zwischengeschaltet " werden, ohne daS dies 
der Programmierer der Griandkomponente ausdriicklich angeben 
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inuSte. Schliefilich kann, wie bereits erwahnt, eine Komponen- 
te auch vom Programmierer bestimmte Andockpunkte an beliebi- 
gen Stellen des Programmablauf s enthalten. In Ausf uhrungs- 
alternativen sind weitere oder andere Andockpunkte moglich. 

5 

Jeder Andockpunkt weist in dem hier beschriebenen Ausfiih- 
rungsbeispiel mehrere Andockstellen ("slots") auf . Dadurch 
konnen mehrere Komponentenerweiterungen an einen einzigen 
Andockpunkt angeschlossen werden. Bei einem Andockpunkt, der 

10 einem Eingabefeld zugeordnet ist, sind beispielsweise eine 
Haupt-Andockstelle und funf Neben -Andockstellen vorgesehen . 
Eine eventuell in der Haupt-Andockstelle eingetragene Kompo- 
nentenerweiterung wird immer dann aufgerufen, wenn der Be- 
nutzer das Eingabefeld aktiviert . Wahlweise kann diese Kom- 

15 ponente auch bei jedem Anzeigen des Eingabef eldes , also 
schon vor einer Benutzeraktion, aufgerufen werden. Die 
Neben-Andockstellen konnen dagegen zum Beispiel dem Betati- 
gen bestimmter Funktionstasten oder anderen Aktionen des 
Benutzers zugeordnet werden. Bei Druckmasken-Ausgabef eldern 

20 kann die Ansteuerung der Andockstellen eines Andockpunkt es 
zum Beispiel durch eine Bedienereingabe zum Startzeitpunkt 
des Druckvorgangs bestimmt werden. In Ausf uhrungsalternati- 
ven sind andere Auf ruf strategien oder andere Anzahlen von 
Andockstellen (beispielsweise nur eine pro Andockpunkt) 

25 moglich. 

Im folgenden wird die Inst ant iierung von Komponenten unter 
Hinweis auf Fig. 3 genauer beschrieben. Wie bereits erwahnt, 
bedeutet Instantiierung die Ubersetzung eines Komponenten- 
30 skripts in mindestens ein Binarobjekt. Im hier beschriebenen 
Ausftihrungsbeispiel wird bei der Instantiierung fur jeden 
gefundenen Andockpunkt genau eine Komponente als Binarobjekt 
erzeugt . 

35 Der Instantiierungsvorgang, der automatisch von dem Genera- 
torsystem durchgefuhrt wird, beginnt mit dem Einlesen des 
Komponentenskripts (Schritt 40) . In Schritt 42 wird nun ein 
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erster Andockpunkt gesucht . Wenn das zu ubersetzende Kompo- 
nentenskript nur die Containeridentif izierung als Verer- 
bungsparameter enthalt, wird ein generischer Andockpunkt in 
der Containerumgebung 18 (Fig. 1) angenommen . Dies ermog- 
5 licht eine Instantiierung von "Wurzelkomponenten" , also Kom- 
ponenten, die keine Komponentenerweiterungen darstellen. 



Enthalt dagegen das zu ubersetzende Komponentenskript einen 
"echten" Vererbungsparameter , so definiert dieser die fur 

10 die Komponentenerweiterung vorgesehenen Andockpunkte . Hier- 
fur bestehen mehrere Moglichkeiten . Wenn zum Beispiel ein 
Eingabefeld einer Bildschinninaske als Andockpunkt dienen 
soli, so kann der Vererbungsparameter sowohl den Feldnamen 
und die gewunschte Andockstelle innerhalb des Andockpunktes 

15 (Nummer des "slots") angeben als auch die Grundkomponente 
spezif izieren. Alternativ ist es auch moglich, im Verer- 
bungsparameter nur den Feldnamen und gegebenenf alls die Num- 
mer des "slots" einzutragen. Als Andockpunkte dienen dann 
alle Stellen in den gegenwartig im Programmkomponentensystem 

20 vorhandenen Binarobjekten, an denen ein Bildschirmf ormat re- 
ferenziert wird, das das genannte Feld als Eingabefeld ver- 
wendet . 



Wenn ein erster Andockpunkt gefunden wurde (Abfrage 44), so 
25 wird zunachst eine geeignete Aufruf information, beispiels- 
weise eine zum Aufruf der Erweiterungskomponente dienende 
Nachricht ("message"), in die den Andockpunkt enthaltende 
Grundkomponente eingetragen (Schritt 45) . Die Grundkomponen- 
te wird dazu im Binarobj ekt format gelesen, der Verweis auf 
3 0 die Erweiterungskomponente wird in die Grundkomponente ein- 
getragen, und das so veranderte Binarobj ekt wird in das Pro- 
grammkomponentensystem zuruckgeschrieben. Der Vererbungs- 
parameter legt dabei fest, an welcher Andockstelle ("slot") 
innerhalb eines Andockpunktes die Auf ruf information einge- 
35 tragen werden soli und welche Benutzeraktion zu einem Aufruf 
der Erweiterungskomponente fuhren soli. 
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Nach der Modif if kation der den gefundenen Andockpunkt ent- 
haltenden Grundkomponente, wird die diesem Andockpunkt zuge- 
ordnete Erweiterungskomponente als Binarobjekt aufgebaut 
(Kasten 48) . Zunachst werden die Andockpunkte der Erweite- 
5 rungskomponente bestimmt und in das entsprechende Verzeich- 
nis im Verzeichnisabschnitt 2 6 der Komponente 20 eingetragen 
(Schritt 50) , Dazu werden alle Bildschirminasken und Druck- 
formate untersucht, auf die das Skript der Erweiterungskom- 
ponente verweist. Ferner erfolgt ein Zugriff auf das globale 

10 Verzeichnis der durch diese Masken und Formate definierten 
Andockpunkte. Die dort enthaltenen Inf ormationen werden als 
Andockref erenzen in den Verzeichnisabschnitt 2 6 ubernommen. 
Neben dem Namen eines eingebundenen Bildschirm- oder Druck- 
feldes sind dies beispielsweise Inf ormationen liber den Feld- 

15 typ, den Speicherplatzbedarf des zugeordneten Datenwertes 
und so weiter . 

Ferner wird das Komponentenskript nach Andockref erenzen 
durchsucht, die vom Programmierer angegeben wurden (Kon- 

20 strukt INTERFACE-IS <Name> ) . Auch diese Andockref erenzen 

werden in den Verzeichnisabschnitt 2 6 ubernommen. Schliefi- 
lich werden auch fur alle im Komponentenskript gefundenen 
Zugriff soperationen auf persistente Daten (Konstrukt zum 
Beispiel READ <Entitatsname>) entsprechende Andockref erenzen 

25 in den Verzeichnisabschnitt 2 6 aufgenommen. 

In einem nachsten Schritt 52 wird die Lauf zeit-Speicherorga- 
nisation instantiiert . Hierzu werden zunachst diejenigen 
Feldbezeichnungen in den von der Erweiterungskomponente re- 

30 ferenzierten Bildschirmmasken und Druckf ormaten bestimmt, 
die nicht bereits in der Grundkomponente definiert sind. 
Diese Feldbezeichnungen werden - sofern sie nicht mit Ein- 
tragen im Zugriff sdatenbereich 3 0 ubereinstimmen - als loka- 
le Variablen der Erweiterungskomponente angesehen, Alle 

3 5 Feldbezeichnungen werden in das Speicherverzeichnis im Ver- 
zeichnisabschnitt 2 6 eingetragen. Ferner wird eine Transfer- 
liste angelegt, urn wahrend der Laufzeit die Bildschiirm- und 
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Druckdaten aus einem Puf f erspeicher in den Speicherbereich 
der Erweiterungskomponente (Zugrif f sdatenbereich 3 0 Oder 
Lokaldatenbereich 32 oder Trans ferdatenbereich 34) zu tiber- 
tragen. Diese Funktion wird zur Laufzeit automatisch aus- 
gefuhrt, ohne dafi eine explizite Prograiiimierung erf order lich 
ware . 

Als weiterer Teil des Schritts 52 werden nun die statischen 
Speicherdefinitionen im Komponentenskript verarbeitet. Da 
die Grundkomponente eindeutig feststeht, konnen schon zur 
Instantiierungszeit die Grogen der drei Datenbereiche 30, 
32, 34 des Binarobjekts 20 ermittelt werden. Ferner kann das 
Speicherverzeichnis im Verzeichnisabschnitt 2 6 vollstandig 
erstellt werden. 

Zunachst werden alle diejenigen statischen Speicherdefini- 
tionen (Konstrukt INHERIT-DATA <Name>) im Komponentenskript 
gesucht, die bereits in der Grundkomponente definiert sind. 
Die entsprechenden Datenwerte finden sich zur Laufzeit im 
Zugrif f sdatenbereich 3 0 an der gleichen S telle (dem gleichen 
Versatz- oder Displacementwert ) wie bei der Grundkomponente, 
da der Arbeitsspeicherbereich 16, der vom Zugrif f sdatenbe- 
reich 3 0 der Grundkomponente belegt wird, beim Aufruf der 
Erweiterungskomponente weiterverwendet wird. In das Spei- 
cherverzeichnis der Erweiterungskomponente werden daher Ein- 
trage aufgenommen, die denen der Grundkomponente entspre- 
chen. Diese Eintrage enthalten den Namen und Typ des Daten- 
wertes sowie die Feldlange und den Displacementwert. 

SchlieSlich werden solche statische Speicherdefinitionen des 
Komponentenskripts verarbeitet, die dem Lokaldatenbereich 3 2 
zugeordnet sind. Dies sind erstens Definitionen von Spei- 
cherfeldern, die in der Grundkomponente nicht definiert 
sind, und zweitens Speicherdefinitionen, bei denen ausdrtick- 
lich eine lokale Speicherung angegeben wurde (Konstrukt 
INHERIT-DATA- LOCAL <Name>) . Ftir derartige Speicherdefini- 
tionen wird eine freie Adresse im Lokalspeicherbereich 32 
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ermittelt und reserviert. Genauer gesagt, wird die nachste 
freie Adresse hinsichtlich des aktuellen Speicherpegels (der 
von der Speicherbelegung der Grundkomponente und eventuell 
schon zugewiesenen lokalen Feldern der Erweiterungskomponen- 
5 te abhangt) verwendet. Auch fiir diese Speicherdef ini tionen 
werden entsprechende Eintrage in das Speicherverzeichnis der 
Erweiterungskomponente auf genommen . 

Als nachster Schritt 54 wird die zur Laufzeit stattf indende 
10 Datenbe- und -entsorgung der Erweiterungskomponente instan- 
tiiert, indem das Datentransf erverzeichnis im Verzeichnis- 
abschnitt 2 6 angelegt wird. Hierzu werden zunachst die 
Datenbe- und -entsorgungsdef initionen im Komponentenskript 
gesucht. Diese Def initionen haben die folgende Form, wobei 
15 INH fur "inherit" und "IME" flir " Import /Export " steht: 

INH-DATA-IME <Identif ikation der Komponente, mit der 

die Datenbe- und -entsorgung stattfindet> 
INTERFACE = <Feldname_l> , 
20 <Feldname_2>, 

• * • / 

<Fe ldname__n> 

ENDTRANSFER 

25 Beim Auffinden einer derartigen Definition wird das Spei- 

cherverzeichnis der adressierten Komponente ausgewertet . In- 
formationen uber die auszutauschenden Datenf elder (Feldtyp, 
Feldlange, Adresse oder Displacement) im Arbeitsspeicherbe- 
reich 16 zur Laufzeit werden eingelesen. Ferner wird ein 

30 entsprechendes Speicherfeld im Trans ferdatenbereich 3 4 re- 
serviert, sofern das adressierte Feld nicht im Zugriffsda- 
tenbereich 3 0 enthalten ist. Aus diesen Inf ormationen wird 
ein entsprechender Eintrag im Datentransf erverzeichnis des 
Verzeichnisabschnitts 2 6 der Erweiterungskomponente erzeugt. 

35 Dieser Eintrag enthalt somit die Zuordnung des Speicherfel- 
des der adressierten Komponente zu dem Speicherfeld im 
Trans ferdatenbereich 34 der gegenwartig instantiierten Kom- 
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ponente . Die adressierte Komponente braucht nicht die Grund- 
komponente zu sein, und das adressierte Speicherfeld in die- 
ser Komponente kann in einem der drei Bereiche 30, 32 und 3 4 
liegen. DemgemaS ist eine Datenbe- und -entsorgung von alien 
5 Daten moglich, die in einer beliebigen anderen Komponente 
verfiigbar sind. 



Nun erfolgt die Codegenerierung (Schritt 56), in der die An- 
weisungszeilen im Komponentenskript in einen geeigneten, von 

10 dem Lauf zeitsystem 14 interpretierbaren Zwischencode umge- 
setzt werden. Die Codegenerierung wird nach an sich bekann- 
ten Grundsatzen ausgefuhrt. Die Komponente wird nun im Di- 
nar objekt format aus den Bestandteilen zusammengebunden, die 
bei den bisher beschriebenen Schritten erzeugt worden sind. 

15 Das result ierende Binarobjekt hat die in Fig. 2 gezeigte und 
oben bereits beschriebene Struktur. Es wird in einem weite- 
ren Schritt gespeichert (Schritt 58) . 

Damit ist die Erzeugung eines Binarobjekts fur einen Andock- 
20 punkt abges Chios sen . Im Instantiierungsverf ahren wird nun 
ein nachster Andockpunkt gesucht (Schritt 60) . Falls ein 
solcher im Programmkomponentensystem vorhanden ist, wird ein 
wei teres Binarobjekt erzeugt; andernfalls ist die Instanti- 
ierung beendet . Die aus einem Komponentenskript erzeugten 
25 Binarobjekte unterscheiden sich hochstens hinsichtlich der 
in dem Speicherverzeichnis definierten Speicherbelegung . 
Wenn in einer Grxindkomponente mehrere Andockpunkte gefunden 
werden, ist diese Speicherbelegung jedoch im Regelfall iden- 
tisch. Dieser Fall kann auch eintreten, wenn mehrere Andock- 
3 0 punkte in verschiedenen Grundkomponenten gefunden werden. In 
einer Ausf lihrungsalternative ist daher zur Optimierung vor- 
gesehen, identische Binarobjekte nur je einmal zu erzeugen. 

Zum Ausfuhren des Programmkomponentensystems wird die in 
35 Fig. 1 dargestellte Struktur aufgebaut. Dazu werden zunachst 
das Lauf zeitsystem 14 und die Containerumgebung 18 geladen 
und gestartet. Die Containerumgebung 18 enthalt einen Kata- 
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log der beim Starten sichtbaren Menueintrage . Dieser Katalog 
wird durch die Komponenten 18 def iniert . Nun wird eine Wur- 
zelkomponente gestartet, die bei dem oben beschriebenen In- 
stant iierungsvorgang von dem Generator system eigenstandig 
5 erzeugt wurde. Das Lauf zeitsystem wartet nun auf ein vom 

Benutzer ausgelostes Ereignis, beispielsweise eine Menuaus- 
wahl. durch das der Aufruf einer " eigentlichen" Komponente 
des Programmkomponentensys terns angezeigt wird. 

In Fig. 4a bis Fig. 4c ist das Programmablauf verf ahren ge- 
zeigt, das beim Komponentenauf ruf sowie beim Ausfuhren der 
aufgerufenen Komponente durchgefuhrt wird. Zur Laufzeit ist 
in dem hier betrachteten Ausf uhrungsbeispiel stets genau 
eine Komponente aktiv. Unmittelbar nach dem Systemstart ist 
dies die oben beschriebene Wurzelkomponente . Nur die jeweils 
aktive Komponente befindet sich im Arbeitsspeicherbereich 
16. Die Komponente hat hierbei die in Fig. 2 gezeigte Binar- 
objektstruktur . In Ausf uhrungsalternativen ist auch ein 
quasi-paralleler Ablauf mehrerer Komponenten (z.B. iiber 
"multi-threading" ) moglich. Die Steuerung erfolgt dann durch 
das zugrundeliegende Betriebssystem 10. 

Wenn eine neue Komponente aufgerufen werden soil, zum Bei- 
spiel in Reaktion auf eine Eingabe oder Aktion des Benut- 
zers, wird zunachst der Zustand der gerade aktiven Komponen- 
te gesichert (Schritt 70) . Dies bedeutet zumindest, dafi der- 
jenige Teil des Arbeitsspeicherbereichs 16 in eine Datei 
Oder einen sonstigen Sicherungsbereich iibertragen wird, in 
dem sich der Speicherbildabschnitt 2 8 der Komponente befin- 
det. Im hier beschriebenen Ausf uhrungsbeispiel wird sogar 
das gesamte Binarobjekt gesichert, well dessen librige Ab- 
schnitte hinsichtlich des Speicherbedarf s nicht ins Gewicht 
fallen. 

Ferner werden alle Datenentsorgungsvorgange durchgefuhrt, 
die wahrend des Ablaufs der bisher aktiven Komponente vorge- 
merkt worden sind (Schritt 72) . Zur Ef f izienzsteigerung ist 
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in dem hier beschriebenen Ausf uhrungsbeispiel namlich vorge- 
sehen, nur diejenigen Speicherf elder des Trans ferdatenbe- 
reichs 34, auf die ein schreibender Zugriff stattgef unden 
hat, wieder von der aktuellen Komponente in die durch die 
5 Datenentsorgung ref erenzierte Komponente zu ubertragen. In 
Ausfuhrungsalternativen erfolgt keine Vormerkung der veran- 
derten Daten, sondern es werden bei jedem Komponentenwechsel 
alle Datenf elder im Trans ferdatenbereich 34 an die jeweils 
ref erenzierten Komponenten ubertragen. 

10 

Bei jedem Datenentsorgungsvorgang wird das Datentransf erver- 
zeichnis der aktuellen Komponente herangezogen, um die refe- 
renzierte(n) Komponente (n) und das entsprechende Datenf eld 
(die entsprechenden Datenf elder) in deren Speicherbildab- 

15 schnitt(en) 28 zu bestimmen und die Daten dorthin zu uber- 
tragen. Durch jede Datenentsorgung wird somit ein Binarob- 
jekt einer gegenwartig nicht aktiven Komponente verandert. 
Wahrend der Laufzeit kann eine Komponente mehrmals aufgeru- 
fen und teilweise ausgefuhrt worden sein. In diesem Fall 

20 sind mehrere Versionen der Komponente gesichert. Die Daten- 
entsorgung findet in diesem Fall in diejenige gesicherte 
Komponentenversion statt, die innerhalb der zur gegenwartig 
aktiven Komponente fuhrenden Aufrufkette dieser Komponente 
am nachsten steht. In Ausfuhrungsalternativen wird eine an- 

25 dere oder vom Programmierer bestimmte Auswahl der zu verwen- 
denden Komponentenversion getroffen. 

Als nachster Schritt 74 wird nun die neu aufgerufene Kompo- 
nente als Binarobjekt in den Arbeitsspeicherbereich 16 gela- 
3 0 den. Dabei wird auf jeden Fall der Teil des Arbeitsspeicher- 
bereichs 16, der fur die Programm- , Tabellen- und Verzeich- 
nisabschnitte 22, 24, 2 6 der alten Komponente benutzt wurde, 
liberschrieben . 

3 5 Auch der Lokaldatenbereich 32 des Speicherbildabschnitts 2 8 
der neuen Komponente wird in den Arbeitsspeicherbereich 16 
geladen. Damit sind beim Start der neuen Komponente alle 
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lokalen Daten mit definierten Standardwerten vorbesetzt. 
Derjenige Abschnitt des Arbeitsspeicherbereichs 16, der dem 
Zugrif f sdatenbereich 3 0 der aufgerufenen Komponente ent- 
spricht, wird jedoch nicht uberschrieben . Damit gehen die 
5 dort gespeicherten Datenwerte beim Komponentenwechsel nicht 
verloren. Die neue Komponente kann vielmehr iiber den Zu- 
grif f sdatenbereich 3 0 unmittelbar auf Speicherf elder zugrei- 
fen, die in der aufrufenden Komponente definiert sind. Die 
Grofie das Zugrif fsdatenbereichs 3 0 bestimmt sich nach der in 
10 der Instantiierungsphase ermittelten Speicher^erteilung . 
Falls die aufrufende Komponente auf vollig andere Werte 
zugreift wie die aufgerufene Komponente, hat der Zugrif fs- 
datenbereich 3 0 die GroSe Null. 

15 Nachdem die aufgerufene Komponente als Binarobjekt geladen 
wurde, wird der im Programmabschnitt 22 enthaltene Code 
Befehl fur Befehl interpretiert . Bei der Ausfuhrung eines 
Befehls (Schritt 76) sind einige Sonderfalle zu beachten, 

2 0 Falls es sich bei dem Befehl urn eine Speicheroperation han- 

delt, deren Ziel der Trans ferdatenbereich 34 ist (Abfrage 
78), dann wird das betroffene Speicherf eld fur eine spatere 
Datenentsorgung vorgemerkt (Schritt 80) . Ein solches Vormer- 
ken ist auch durch einen ausdriicklichen Befehl moglich. 

25 

Handel t es sich bei dem aktuellen Befehl urn eine Anweisung, 
die eine Datenbesorgung aus einer ref erenzierten Komponente 
veranlafit (Abfrage 82), so werden die in Fig. 4b gezeigten 
Schritte ausgef iihrt . Ein derartiger Befehl ist zum Beispiel 
30 das oben bereits beschriebene Konstrukt INH-DATA-IME, das im 
hier beschriebenen Ausf lihrungsbeispiel sowohl als Deklara- 
tion einer Datenbe- und -entsorgungsbeziehung als auch als 
Anweisung zur Datenbesorgung aufgefaSt wird. In Ausfiihrungs- 
alternativen werden schon beim Start einer Komponente alle 

3 5 von dieser ref erenzierten Daten besorgt. 
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Bei dem Datenbesorgungsverf ahren nach Fig. 4b wird zunachst 
gepriift, ob die ref erenzierte Komponente bereits ( ziimindest 
teilweise) ausgefuhrt wurde (Abfrage 84) . 1st dies nicht der 
Fall, so konnen keine gultigen Daten besorgt werden, und ein 
5 Lauf zeitfehler wird ausgelost. Falls dagegen eine gesicherte 
Version der ref erenzierten Komponente vorhanden ist, werden 
die benotigten Daten daraus geladen und in den Transfer- 
datenbereich 3 4 der gegenwartig aktiven Komponente geschrie- 
ben. Die jeweiligen Speicherplatze in der ref erenzierten und 

10 der aktiven Komponente sind aus dem Datentransf erverzeichnis 
der aktiven Komponente ersichtlich. Auch hier kann es (ahn- 
lich wie in Schritt 72) vorkommen, daS mehrere Versionen der 
ref erenzierten Komponente gespeichert sind. Es wird dann 
diejenige Version zur Datenbesorgung herangezogen, die in 

15 der zur aktiven Komponente fiihrenden Aufrufkette zuletzt 
ausgefuhrt wurde. In Ausf uhrungsalternativen sind andere 
vorgegebene oder programmierbare Auswahlstrategien moglich. 
Nach dem Ende der Datenbesorgung wird der Programmablauf bei 
Schritt 76 (Fig. 4a) fortgesetzt. 

20 

In Abfrage 88 {Fig. 4a) wird liberpruft, ob es sich bei dem 
aktuell interpret ier ten Befehl urn einen Befehl zum Komponen- 
tenwechsel, also zum Aufruf einer neuen Komponente, handelt. 
Ein solcher Befehl kann insbesondere eine in einem Andock- 

25 punkt gespeicherte Aufruf information (message) sein. Wie 

bereits beschrieben, fiihrt eine solche Aufruf info2rmation je 
nach der Art des Andockpunktes entweder durch ihr bloSes 
Vorhandensein oder bei einer vorbestiinmten Aktion des Benut- 
zers zum Aufruf der in der Aufruf information angegebenen 

3 0 Komponente. Wenn ein solcher Aufruf stattfindet, wird der 
aktuelle Bef ehlszahlerstand in einem Stapelspeicher gesi- 
chert und eine neue Instanz des in Fig. 4a dargestellten 
Verfahrens wird begonnen. 

35 Abfrage 90 betrifft schlieElich den Fall, daS die Ausfuhrung 
der aktuellen Komponente regular beendet wird. 1st dies 
nicht der Fall, so wird die Programmausf uhrung mit Schritt 
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76 fortgesetzt. Falls dagegen das Programmende erreicht ist, 
wird das in Fig. 4c dargestellte Verfahren ausgeflihrt. Es 
werden zunachst, ahnlich wie in Schritt 72, alle vorgemerk- 
ten Datenentsorgungen ausgefuhrt (Schritt 92) . Daraufhin 
wird der Zustand derjenigen Komponente im Arbeitsspeicher- 
bereich 16 wiederhergestellt , die die aktuelle Komponente 
aufgerufen hat (Schritt 94) . Dies betrif ft die Abschnitte 
22, 24 und 26 sowie den Lokaldatenbereich 32. Der Abschnitt 
des Arbeitsspeicherbereichs 16, der dem Zugrif f sdatenbereich 
3 0 der aufrufenden Komponente entspricht, wird dagegen nicht 
wiederhergestellt , so daS eine Ruckgabe von Werten im Zu- 
grif f sdatenbereich 3 0 von der aktuellen Komponente zur auf- 
rufenden Komponente moglich ist. 

Nach dem Wiederherstellen der aufrufenden Komponente ist die 
gegenwartige Instanz des in Fig. 4a bis Fig. 4c gezeigten 
Verfahrens beendet . Die Pr ogrammaus f lihrung wird in der frii- 
heren Instanz an der Stelle fortgesetzt, an der der ur- 
spriingliche Komponentenauf ruf ausgelost wurde (Schritt 76) . 

Durch die hier geschilderten Verfahren ist eine Funktionali- 
tatserweiterung von Komponenten auf relativ einfache Weise 
moglich. Beispielsweise sei eine Grundkomponente gegeben, 
die ein Preisf indungsverf ahren realisiert, das auf einem vom 
Benutzer (iiber ein Eingabefeld) einzugebenden Einzelpreis 
basiert. Mittels einer geeigneten Erweiterungskomponente 
kann diese Grundkomponente um ein anwendungsbezogenes Preis- 
f indungsverf ahren fur den Einzelpreis erweitert werden. Die 
Auf ruf information fur die Erweiterungskomponente wird dazu 
in einen Andockpunkt geschrieben, der dem Eingabefeld fiir 
den Einzelpreis zugeordnet ist. Der von der Erweiterungs- 
komponente ermittelte Einzelpreis wird durch das Datenent- 
sorgungsverf ahren in die Grundkomponente eingeschrieben . 
Weitere Datenwerte, die die Erweiterungskomponente zur 
Preisf indung benotigt, werden durch das Datenbesorgungs- 
verf ahren aus anderen Komponenten abgerufen. Es ist nicht 
erf orderlich, daS bei der Programmierung der Grundkomponente 
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Oder der anderen Komponenten die Moglichkeit einer solchen 
Funktionalitatserweiterung berucksichtigt wurde . 

Die Programmierung von groSeren Sof twaresys temen laEt sich 
auf unterschiedliche Weise vereinf achen . Zxim Beispiel ist es 
moglich, sogenannte " Adapt erkomponenten" zu definieren. Eine 
Adapterkomponente ist eine Erweiterungskomponente , die 
uninittelbar eine andere Komponente ref erenziert . Dadurch 
kann die andere Komponente mehrfach unter verschiedenen 
Namen verwendet werden. 
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Anspruche 



10 



1. Prograiranablaufverfahren bei einem Programmkomponenten- 
system, das ein Lauf zeitsystem (14) und mehrere Komponenten 
(20, 20', ...) mit je einem Programmabschnitt (22) aufweist, 
mit den folgenden Schritten beim Ausfuhren des Prograininab- 
schnitts (22) einer ersten Komponente (20): 

a) durch das Lauf zeitsystem (14) veirmittelte Datenbesor- 
gung von Daten einer zweiten Komponente (20') in die erste 
Komponente (20) unabhangig von prograiruniererdef inierten 
Schnittstellen in der zweiten Komponente (20'), und 

b) durch das Lauf zeitsystem (14) vermittelte Datenentsor- 
gung von Daten der ersten Komponente (2 0) in die zweite 

15 Komponente (20*) unabhangig von programmiererdef inierten 
Schnittstellen in der zweiten Komponente (20*). 

2 . Verf ahren nach Anspruch 1 , 

dadurch gekennzeichnet , da£ die bei der Datenbesorgung tiber- 
20 mittelten Daten von einem Speicherbildabschnitt (28) der 

zweiten Komponente (20') in einen Trans ferdatenbereich (34) 
der ersten Komponente (20) ubertragen werden, und/oder daS 
die bei der Datenentsorgung ubermittelten Daten von einem 
Transferdatenbereich (34) der ersten Komponente (20) in 
25 einen Speicherbildabschnitt (28) der zweiten Komponente 
(20') Ubertragen werden . 



3 . Verf ahren nach Anspruch 1 oder Anspruch 2 , 
dadurch gekennzeichnet , dafi die Datenbe- und/oder -entsor- 
30 gxing ohne Mitwirkung der zweiten Komponente (20') erfolgt. 

4 . Verf ahren nach einem der Anspruche 1 bis 3 , 

dadurch gekennzeichnet , daS die zweite Komponente (20') bei 
der Datenbe- und/oder -entsorgung inaktiv ist. 

35 

5. Verf ahren nach einem der Anspruche 1 bis 4, 
dadurch gekennzeichnet , daS sich der Transferdatenbereich 
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(34) der zweiten Komponente (20') bei der Datenbe- und/oder 
-entsorgung in einem Sicherungsbereich befindet. 

6. Verfahren nach einem der Anspruche 1 bis 5, 

5 dadurch gekennzeichnet , dag bei der Datenbe- und/oder 
-entsorgung lokale und/oder nicht-persistente Daten der 
zweiten Komponente (20') ubeirmittelt werden. 

7. Verfahren nach einem der Ansprtiche 1 bis 6, 

10 dadurch gekennzeichnet, daS beim Ausfiihren des Programmab- 
schnitts (22) der ersten Komponente (20) vorgemerkt wird, 
fiir welche Daten der ersten Komponente (20) eine Daten- 
entsorgung erforderlich ist. 

15 8. Verfahren nach einem der Anspruche 1 bis 7, 

dadurch gekennzeichnet, daS eine aufgerufene Komponente (20, 
20', ...) unmittelbar auf einen Zugrif f sdatenbereich (30) 
zuzugreifen vermag, der die in der aufrufenden Komponente 
(20, 20', ...) definierten und/oder verfugbaren Datenfelder 

2 0 en thai t. 

9. Verfahren nach einem der Anspruche 1 bis 8, 

dadurch gekennzeichnet, dafi der Aufruf einer Komponente (20, 
20', ...) durch eine Auf ruf information ausgelost wird, die 
25 in einem Andockpunkt der aufrufenden Komponente en thai ten 
ist. 

10. Verfahren zur Earweiterung eines mehrere Komponenten 
(20, 20', ...) aufweisenden Programmkomponentensys terns urn 

3 0 eine weitere Komponente, mit den Schritten: 

a) Suchen von Andockpunkten fur die weitere Komponente, 
die einem durch eine Definition der weiteren Komponente be- 
stimmten Vererbungsparameter entsprechen, in dem Programm- 
komponentensys tern , und 
35 b) Andern derjenigen Komponenten (20, 20', ...) des Pro- 
grammkomponentensys terns , in denen mindestens ein Andockpunkt 
gefunden wurde, indem an jedem gefundenen Andockpunkt eine 
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Aufruf information auf die weitere Komponente eingetragen 
wird. 

11. Verfahren nach Anspruch 10, 
5 dadurch gekennzeichnet , daS alle Interaktionsschnittstellen 
der bisherigen Komponenten (20, 20', ...) als potentielle 
Andockpunkte vordefiniert sind. 



12. Verfahren nach Anspruch 10, 

10 dadurch gekennzeichnet, dag alle von den bisherigen Kompo- 
nenten (20, 20' , . , . ) referenzierten Interaktions-Bild- 
schirmfelder und/oder alle Druckmasken-Ausgabef elder und/ 
Oder alle Zugrif f soperationen auf persistente Daten als 
potentielle Andockpunkte vordefiniert sind. 

15 

13. Verfahren nach einem der Anspruche 10 bis 12, 
dadurch gekennzeichnet, dag durch das Eintragen der Aufruf - 
information in einen Andockpunkt ein Aufruf der weiteren 
Komponente aus der Komponente, in die die Auf ruf information 

20 eingetragen wurde, vorbereitet wird. 

14. Verfahren nach einem der Anspruche 10 bis 13, 
gekennzeichnet durch den weiteren Schritt: 

c) Erzeugen mindestens eines Binarobjekts aus der Defini- 
25 tion der weiteren Komponente. 

15. Verfahren nach Anspruch 14, 

dadurch gekennzeichnet, dag fur jeden gefundenen Andockpunkt 
hochstens ein Binarobjekt erzeugt wird. 

30 

16. Verfahren nach Anspruch 15, 

dadurch gekennzeichnet, dag bei der Erzeugung jedes Binar- 
objekts die Speicherzuteilung in derjenigen Komponente (20, 
20' , . . . ) des Programmkomponentensys terns beriicksichtigt 
35 wird, die den zugrundeliegenden Andockpunkt enthalt. 



BLANK (USPTO) 



THVS 



wo 99/35571 



2/4 



PCT/EP98/08507 







Komponentenskript lesen 






ersten Andockpunkt suchen 




•40 



■42 



nein 



Eintrag Aufrufinformationen 
in Grundkomponente 



Aufbau von Andockreferenzen 



Instantiierung der 
Laufzeit-Speicherorganisation 



Instantiierung der 
Datenbe- und -entsorgung 



Codegeneriemng 



Schreiben Binarobjekt 



nachsten Andockpunkt suchen 



•46 



•50 



■52 



•54 



■56 



•58 



.48 



J 



■60 



FIGS 



wo 99/35571 



3/4 



PCT/EP98/08507 







sichere Zustand der aktiven 
Komponente 




r 


fuhre vorgemerkte 
Datenentsorgungen durch 



•70 



■72 



FIG 4a 



lade Binarobjekt 



■74 



interpretiere nachsten Befehl 



.78 

Speicher- 
[operation auf Transferbereich, 
als Ziel ? ^ 



nein 



,82 



Datenbe- 
_sorgung aus anderer Kompq^ 
^ nente ? ^ 



nein 
Aufruf 

einer neuen Komponente 
? 

nein 

"Programm- 
^nde der aktuellen KompO; 
nente?, 

nein 



,88 



,90 



ja 



■76 



80 



Datenentsorgung 
vormerken 





THIS PAGE BLANK (uspto) 



wo 99/35571 PCT/EP98/08507 

4/4 




Daten laden und in 
Transferdatenbereich speichern 



■86 



FIG 4b 








vorgemerkte Dal 
durchi 


enentsorgungen 
fiihren 






Wiederherstellen der 
aufmfenden Komponente 




r 



FIG 4c 




■92 



■94 




THIS RAGE BLANK (uspto) 



evternaTional search report 



Inl itional Application No 

PCT/EP 98/08507 



A. CLASSIFICATrON OF SUBJECT MATTER 

IPC 6 G06F9/44 



According to (ntemational Patent Classification (IPC) or to both national class tftcation and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 

IPC 6 G06F 



Documentation searched other than minimum documentation to the extant that such documents are included in the fields searched 



Electronic data base consulted duhng the international search (name of data base and, where practical, search terms used) 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Categor/ ■ 



Citation of document, with Indication, where appropriate, of the relevant passages 



Relevant to claim No. 



PURTILO J M ET AL: "IMPROVING MODULE 
REUSE BY INTERFACE ADAPTATION" 
PROCEEDINGS OF THE INTERNATIONAL 
CONFERENCE ON COMPUTER LANGUAGES, NEW 
ORLEANS, MAR. 12 - 15, 1990,12 March 1990, 
pages 208-217, XP000289137 
INSTITUTE OF ELECTRICAL AND ELECTRONICS 
ENGINEERS 

see page 208, right-hand column, line 1 - 
1 ine 33 '■ 
see page 209, left-hand column, line 1 - 
page 210, left-hand column, line 22 

WO 95 29440 A (BRITISH TELECOMM ; JONES 
COLIN (GB); DHALIWAL MANDEEP SINGH (GB); 
K) 2 November 1995 
see page 1, line 1 - page 6, line 32 

-/-- 



1-16 



1-16 



Further documents are listed in the continuation of box C. 



Patent family members are listed in annex. 



* Special categories of cited documents : 

"A" document defining the general state of the art which is not 

considered to be of particular relevance 
"E" earlier document but published on or after the international 

filing date 

"L" document which may throw doubts on priority claim(s) or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

"O" document referring to an oral disclosure, use, exhibition or 
other means 

"P" document published prior to the international filing date but 
later than the priority date claimed 



'T" later document published after the international filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underiying the 
invention 

"X" document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taken alone 

"Y" document of particular relevance: the claimed invention 

cannot be considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
in the art. 

"&" document member of the same patent family 



Date of the actual completion of the intemational search 



30 June 1999 



Date of mailing of the international search report 



07/07/1999 



Name and mailing address of the ISA 

European Patent Office, P.B. 5818 Patentlaan 2 
NL - 2280 HV Rijswijk 
Tel. (+31-70) 340-2040, Tx. 31 651 epo nl, 
Fax: (+31-70) 340-3016 



Authorized officer 



Brandt, J 



Form PCT/ISA/21 0 (second sheet) (July 1992) 



page 1 of 2 



INTERNATIONAL SEARCH REPORT 



national Application No 

PCT/EP 98/08507 



C.(Contlnuation) DOCUMENTS CONSIDERED TO BE RELEVANT 



Category Citation of document, with tndication.where appropriate, of the relevant passages 



Relevant to ctaim No. 



us 5 634 124 A (KHOYI DANA ET AL) 
27 May 1997 

see column 3, line 32 - column 4, line 25 

"PROGRAMMING LANGUAGE INDEPENDENT 
INTERFACE FOR REUSABLE PROGRAMMED 
COMPONENTS" 

IBM TECHNICAL DISCLOSURE BULLETIN, 

vol. 38, no. 7, 1 July 1995, page 299/300 

XP000521698 

see the whole document 



1-16 



1-16 



Fofm PCT/(SA/210 (continuation of second sheet) (July 1992) 



page 2 of 2 



INTERMBTIONAL SEARCH REPORT 

Information on patent family members 



Int tlonal Application No 

PCT/EP 98/08507 



Patent document 


Publication 




Patent family 




Publication 


cited in search report 


date 




member(s) 




date 


WO 9529440 A 


02-11-1995 


AU 


67Q637 


R 


03-07-1 QQ7 






2261795 


A 


1 g-l 1 _1 QQC 




CA 


2187925 

Cm X\i l J 


A 






EP 


0756725 


A 


05-02-1 QQ7 




JP 


9512358 


T 
1 


OQ-l 2-1 QQ7 

U7 XiL X77/ 


US 5634124 A 


27-05-1997 


US 


5421012 


A 


30-05-1QQ5 




u<; 


^226161 


A 


06-07-1 QQ3 




u^ 


ti206Q51 


A 


27-04-1 QQ3 

Cm i Wt X -7 7 ^ 




US 


5421015 


A 


30-05-1 QQ5 




u^ 


5261080 


A 


no-i 1 -1 QQ'^ 




us 




A 


1 2-04-1 QQ3 




AU 




D 


1 4-03-1 QQ 1 

It U J J. 77 X 




AU 


20Q4'^88 


A 


1707 




CA 


1289255 


A 


17-09-1991 




DE 


3856038 


D 


13-11-1997 




DE 


3856038 


T 


23-04-1998 




DE 


3856313 


D 


08-04-1999 




EP 


0304071 


A 


22-02-1989 




EP 


0637806 


A 


08-02-1995 




JP 


1126736 


A 


18-05-1993 



Form PCT/ISA/210 (patent family annex) (July 1992) 



i 



